See also LWG4126. As there's already an accepted LWG issue, I want the changes here to be handled editorially.

I think it's more consistent to ensure feature-test macros for fully freestanding features are also freestanding.

If that is the case, then maybe all of __cpp_lib_ranges_* FTMs should be marked as freestanding? Currently, the ones representing new range algorithms are not marked, but these algorithms themselves are already freestanding given that [algorithm.syn] does have // mostly freestanding attached as the result of the acceptance of P2976 at Hagenberg (#7706).

P2976 does not discuss FTM changes much, only adding __cpp_lib_freestanding_{execution,random}. I'm not closely following the discussion of that paper enough to understand if this is a conscious design decision or simply forgetting to update the comments on the __cpp_lib_ranges_* FTMs (since normal algorithms don't have FTMs, only range algorithms had). I looked into the notes of two times that P2976 was reviewed, in Tokyo (notes) and in Hagenberg (notes), and ranges algorithms doesn't seem to be discussed at all. Hopefully, this still counts as editorial?

If that is the case, then maybe all of __cpp_lib_ranges_* FTMs should be marked as freestanding?

Probably yes except for __cpp_lib_ranges_generate_random. It's unclear to me whether ranges::generate_random is suitable for freestanding. And even if so, an LWG issue is necessary to make it freestanding.

IIUC that the following FTMs should also be freestanding. Some of them should have been so when adopting LWG4126, but I overlooked them.

• __cpp_lib_array_constexpr
• __cpp_lib_aligned_accessor
• __cpp_lib_clamp
• __cpp_lib_constexpr_numeric
• __cpp_lib_function_ref
• __cpp_lib_gcd_lcm
• __cpp_lib_integer_comparison_functions
• __cpp_lib_ranges_contains
• __cpp_lib_ranges_find_last
• __cpp_lib_ranges_fold
• __cpp_lib_ranges_iota
• __cpp_lib_ranges_starts_ends_with
• __cpp_lib_robust_nonmodifying_seq_ops
• __cpp_lib_sample
• __cpp_lib_saturation_arithmetic

is_sufficiently_aligned (with __cpp_lib_is_sufficiently_aligned) is in a weird state. P2897R7 indicated that is_sufficiently_aligned should be freestanding, but the merged wording didn't say so. Not sure where there should be an LWG issue.

Changes done.
I included making is_sufficiently_aligned and its FTM in freestanding for now, since I think it is an omission that should be editorially synced to match the original intent of the paper; if it is decided that this should be a separate LWG issue the change can be easily split out.

I don't think this is editorial. Please file an LWG issue if you think the status quo is defective.

I'm hoping this helps with any LWG issues that get filed...

LWG4189 didn't add most of , P1642R11 added most of ranges. LWG4189 added cache_latest and then changed the editorial style, using "// mostly freestanding" at the header level instead of dozens of "// freestanding" at the declaration level.

I think __cpp_lib_ranges_enumerate could go freestanding with an LWG issue, because all the facilities were freestanding in the initial paper. I'll have to look more to see if these non-freestanding FTMs could move as well, they all seem plausible...

• #define __cpp_lib_ranges_contains 202207L // also in <algorithm>
• #define __cpp_lib_ranges_find_last 202207L // also in <algorithm>
• #define __cpp_lib_ranges_fold 202207L // also in <algorithm>
• #define __cpp_lib_ranges_iota 202202L // also in <numeric>
• #define __cpp_lib_ranges_starts_ends_with 202106L // also in <algorithm>

__cpp_lib_ranges_reserve_hint should not be freestanding, as the paper modifies things that aren't freestanding (like ranges::to). If a freestanding implementation happens to support the entire paper, then that implementation should define __cpp_lib_ranges_reserve_hint.

__cpp_lib_ranges_generate_random lives in , and not . Maybe it could be freestanding one day, but someone would need to test it. I haven't done so. When the paper was written, wasn't freestanding at all yet.

is_sufficiently_aligned on it's own is close to editorial. The design says it should be freestanding, but the wording doesn't say it. LWG issue would be super easy too.

These also seem plausible, just be sure to audit the originating paper to ensure that there weren't other hosted facilities in the paper

• __cpp_lib_array_constexpr
• __cpp_lib_aligned_accessor
• __cpp_lib_clamp
• __cpp_lib_constexpr_numeric
• __cpp_lib_function_ref
• __cpp_lib_gcd_lcm
• __cpp_lib_integer_comparison_functions
• __cpp_lib_robust_nonmodifying_seq_ops
• __cpp_lib_sample
• __cpp_lib_saturation_arithmetic

Also, apologies for not doing the audit of existing feature test macros with P2976R1.